Method and device for characterising a data flow in a network for transferring data

ABSTRACT

A method for characterising a data flow to be transferred over a network path of a network, whereby the network path has at least one network device susceptible of network congestion. The method includes the step of determining a footprint measure of the data flow. The footprint measure is indicative of a possible difference between the total amount of incoming data and the total amount of outgoing data in the network device over a time interval having a duration of one or more time units, whereby that time unit is so chosen that individual data units of the data flow are distinguishable at byte level by the network device. The invention also relates to a device for performing the method.

FIELD OF THE INVENTION

The present invention generally relates to the field of data transfer,in particular media data transfer, over IP networks.

BACKGROUND OF THE INVENTION

The advent and maturing of Internet technology over the last few decadeshas totally changed the landscape of the information technology (IT)industry. The absolute success and popularity of (mostly Ethernet based)Internet Protocol (IP) networks has promoted this technology as theprime architectural choice in most IT environments. Central mainframecomputers have in most cases been replaced by distributed client-serverarchitectures connected by very powerful IP networks.

This technology is steadily being introduced in other industries aswell. Although adoption and above all acceptance of these newtechnologies was at first occurring rather slowly in the media world, IPbased architectures are now fully accepted as the standard solution forfile based media production and have drastically changed the waybroadcasters operate and function internally.

FIG. 1 illustrates how broadcasters have been operating for long in asequential video tape based workflow model. Since video tapes were usedas physical carrier of the essence material, the person in possession ofthe video tape had sole and single access to the material. Distributingcopies of the same material to other people had to be accomplished byplaying out the video tape in real time and record it on another taperecorder(s). In order to perform all tasks in the production workflow,the tasks were executed in a sequential or linear way, each time handingover the result, stored on video tape, to the next workstation. Metadatawas typically passed along the video cassette on small paper slips orattached post-its. This led to long lead times in production ordead-lines well before the moment of broadcasting on antenna.

In recent years broadcasters have finally started to embrace Internettechnology in their production back-office, leading to a collaborativeworkflow model. Applying an ICT based infrastructure and IP networks asmeans of transport, in particular in video/media production, introducesa number of substantial possible benefits, facilitating the fundamentalshift from traditional tape-based video manipulation to a file-basedproduction paradigm. This technology leap enables video to be treated,processed, stored and transported as ordinary files independent of thevideo format, instead of the continuous streams used by the classicalmedia technology of today. Amongst others, the most profound technologychanges are:

-   -   IP-network based access and transport of the media    -   Central disk-based media storage    -   Server-based (non-linear) video editing or processing    -   Software-based media management and media production systems        Together with the appearance of standards like MXF (Material        eXchange Format) and AAF (Advanced Authoring Format), which        provide for a generic file-container for the media essence,        these changes lead to the file-based paradigm of media essence.        As a practical consequence, this brought some of the major        broadcasters to their ‘tape-less’ TV production vision. This        idea is further supported by the appearance of camera devices        with storage facilities other than the traditional videotapes,        e.g. optical disks (Sony) or Solid State memory cards        (Panasonic).

Typically camera crews now enter the facilities with their video storedas ordinary files on memory cards in stead of on video tape. The memorycards are put into ingest stations, e.g. ordinary PCs, and the files aretransferred as fast as possible, preferably faster than real time, intoa central disk based storage system. Once stored in the central system,everybody can access the material simultaneously. Most video operations,such as visioning, video selection, high resolution editing inpostproduction, sonorisation, subtitling, annotation and even archivingcan be performed in parallel without different people having to wait foreach other. This leads in principle to a much more efficient workflow,provided this new workflow and the underlying data flows make optimaluse of the benefits and opportunities created by this architecture.Production lead times should become shorter and dead-lines should becloser to the moment of broadcasting on antenna.

A typical example of such a file based infrastructure is schematicallydepicted in FIG. 2. On the left hand side, the video sources aredepicted. These include uploads from tape based old archives, real-timefeeds, tape based inputs (video players), file based camera inputs andproduction servers in studios. On the top, one finds the non-linear,file-based, high resolution software-based editing suites, both local oron a remote site. On the right hand side, several play-out channels arelisted, including classical linear broadcasting and internet web farms.A web farm is a group of web servers serving different web sites,whereby each web site is administered by its own webmaster andcentralized monitoring provides load balancing and fault tolerance. Allthese peripheral systems are connected via a central IP network with thecentral infrastructure, which provides a massive central storagewarehouse for different flavours of the media, e.g. high resolutionvideo, low resolution proxy video and audio. Additional central servicessuch as trans-coding and backup/archiving are also included. All mediaessence is managed by a central Media Asset Management (MAM) system.

An example of a simple workflow may be the ingest of a video clip from afile based camera into the central storage and the selection of thematerial and transport to the high resolution editing work centre. Theworkflow consists of essentially 3 steps:

-   -   The material is transferred from the memory card of the        file-based camera into the central storage system.    -   A low resolution proxy is created so that any journalist can        view the material and select the relevant clips. The journalist        creates an editing decision list (EDL) to mark his selection.    -   The system uses this EDL to transport the selected pieces of        material to the non-linear file-based editing suite. There the        journalist together with the professional editing technician        performs the editing and creates the result again as a media        file, or multiple media files.        In the earlier tape-based linear era this workflow would also        consist of three consecutive steps:    -   The camera crew comes in with the media material on a video tape        and hands the tape over to one of the journalists.    -   The journalist views the tape to select the relevant shots and        notes the time codes.    -   The journalist takes the original tape to the tape-editing work        centre where a professional editing technician spools the tape        back and forth to the noted time codes and records the resulting        video, together with some effects, back on a final new video        tape.        Remark that in the linear tape-based workflow, the steps have to        be executed one after the other and only one person can use the        material at the same time. In the non-linear flow, material can        be accessed by multiple persons. As soon as the first frames of        the material are being transferred to the central storage, the        creation of the first frames of the low resolution version is        started and any journalist can start viewing the low resolution        proxy. The moment the first selection is made, the corresponding        high material can already be transferred to the editing suite,        where the final editing can start.

When translating to an actual data flow, the data transfers required toexecute this workflow for each ingested clip give rise to an actual dataflow which is clearly much more complex than the simple workflow wouldsuggest. There are several reasons for this unexpected complexity.File-based media solutions first appeared in the separate work centresas small islands, e.g. non-linear editing systems with the size of asmall workgroup, each with their own local small IP network, their ownstorage and some servers and clients. Further, most of the times theoriginal tape-based linear workflow is simply mimicked on the overallfile-based architecture by connecting the file-based work centresolutions together with an central IP network and performing the samelinear workflow as before, but now using files in stead of tapes.Thirdly, since the file-based architecture of the individual workcentres has not been optimized to fit efficiently in an integratedoverall file-based workflow, a lot of extra file transfers are required.E.g. trans-coding is a separate work centre from the central storage.Hence, format conversion to proxy video requires fetching the video fromthe central storage, transporting it over the central IP network to thetrans-coding engines, trans-coding there locally and transporting theresult back again to the central storage. If this trans-coding processconsists of several consecutive steps, multiple transfers back and forthover the central IP network are required. Different work centres fromdifferent vendors require different patterns of MXF file wrappers. Thisis the way in which media is packed into a file or multiple files. E.g.the camera stores video and audio each in a separate file. The mediaasset management system requires the media to be stored in one singlefile on the central storage. While the editing work centre again onlydeals with separate video and audio files. Using IT technology likedisk-based storage requires additional operations typically not used ina video tape-based classical broadcast environment, such as, mirroring asecond copy on a separate storage system, making several back up copieson data-tape, both on-line in a tape-robot, or off-line on a tape shelf.These extra operations have mainly to do with redundancy and/or dataprotection schemes, such as back up and recovery, which are standardprocedure for the IT industry. Lack of trust between media engineers andIT architects results in storing extra copies of the media, to be extrasure not to loose the essence because of failing technology. Most of thetime, the mapping of the work flow on the actual data flow and resultingfile transfers is done ad hoc and not well documented by the suppliersof the media work centre solutions or the overall integrator.

At peak time, when many of the different workflows are executed at thesame time, as many as 500 or more simultaneous file transfers may belaunched on the central infrastructure. Evidently, this puts a very highand largely unexpected load on the central IP network. Transfers sharethe bandwidth on some of the links and server interfaces on the network.The network becomes oversubscribed, with mutual interference ofdifferent transfers as a consequence. On top of this, IT traffic isintrinsically different from media traffic. Files are much longer.Traffic is burstier. Consequently, an IP network, such as it is usuallydesigned in a classical IT environment, reacts differently to this newkind of traffic, with unexpected delays and even broken transfers asresult. Packet loss is far less acceptable when dealing with mediafiles. Whereas a slow e-mail is still an e-mail, a slow video is nolonger a video.

The need for a system to handle adequately the data transferrequirements of multimedia systems, particularly broadcast qualityvideo, was already recognised in patent document U.S. Pat. No.6,223,211. It proposes a system wherein the problems of latency, flowcontrol and data loss are overcome and data movement within a clientsystem memory in a distributed multimedia system is minimized so as toenable real-time transmission of broadcast quality media data over thenetwork. Latency is reduced by an estimation by the server of clientneeds. Data loss is prevented and flow control is provided by permittingthe server to send only as much information as the network interface canreliably receive. Data movement is minimized by copying data directlyfrom the network interface to memory of input/output devices such asdisplay and audio processors as well as main memory.

In the paper “Packet Spacing: an enabling mechanism for deliveringmultimedia content in computational grids” (A. C. Feng et al., Journalof Supercomputing, vol. 23, pp. 51-66, 2002) the authors mention theyobserved significant packet loss even when the offered load was lessthan half of the available network bandwidth. This behaviour was foundto be due to simultaneous bursts of traffic coming from clientapplications and overflowing the buffer space in the bottleneck router.Metaphorically, this could be viewed as what happens at a major highwayinterchange during rush hour where everyone wants to go homesimultaneously at 5 μm, thus “overflowing” the highway interchange. Toavoid such a situation, some people self-regulate themselves by headinghome at a different time, i.e., spacing themselves out from otherpeople. Similarly, a solution is proposed wherein packets are spaced outover time. The inter-packet spacing with control feedback enableUDP-based applications to perform well, as the packet loss can bereduced considerably without adversely affecting the deliveredthroughput.

A similar approach was presented in the paper “Performance Optimizationof TCP/IP over 10 Gigabit Ethernet by Precise Instrumentation” (Yoshinoet al., ACM/IEEE Conference on High Performance Computing, SC2008,November 2008, Austin, Tex., USA), where long-distance large-bandwidthnetworks are discussed. The paper deals with the difficulties to besolved before utilizing Long Fat-pipe Networks (LFNs) by using TCP. Oneof the identified problems is the short-term bursty data transfer. Aprecise packet analyzer is disclosed that is capable of analyzing thereal data transfer over 10 GbE LFNs. In order to avoid packet loss apacket pacing method is used.

European patent document EP1427137 relates to characterising thebehaviour of network devices in a packet based network based on in-linemeasured delay and packet loss. It describes a measurement architectureto obtain per-hop one-way delay between input and output interfaces ofthe same network device. It does so by generating packet headers withassociated timestamps at the mentioned relevant interfaces andinternally, within the same device, comparing the timestamps in therelated headers of the same packets. A second additional measuringstrategy is developed to determine the number of lost packets across anetwork device and between different consecutive network devices.Packets belonging to the same flow are filtered and/or identified in atrace. Packets in the trace are correlated to detect and count missingpackets over a certain time interval.

In WO97/37310 is disclosed a method for monitoring the performance alonga virtual connection in an ATM network. In ATM this performance ismainly expressed in terms of acceptable cell delay and acceptable cellloss rate. In the method, a new type of management packets are beinginserted additionally into the path of the virtual connection taking thesame route as the original actual data packets, in order for these extramanagement packets to experience the same QoS as the data packets.Information about both packet loss and packet delay is measured at theindividual nodes and gathered in the fields of the payload, therebychanging the payload of the management packets. At the end point of thevirtual connection, both individual node delay/packet loss andcumulative delay/packet loss can be extracted out of the resultingpayload. The intention is to allow in-service monitoring to be used toaccurately define the QoS actually seen by users and to detect exactcauses of performance deterioration before users are seriously affected.

The paper “Adaptive bandwidth control for efficient aggregate QoSprovisioning” (Siripongwutikom et al., Globecom'02, November 2002, pp.2435-2439) proposes an adaptive bandwidth control algorithm to provideQoS defined by guaranteed aggregated packet loss and optimal bandwidthallocation. Its basic assumption states that static bandwidth allocationfails due to the lack of a detailed characterisation of input aggregatetraffic, being specified most of the time roughly only in terms of thelong term average rate or peak rate. In the lack of such acharacterisation, it describes as an alternative an adaptive fuzzyfeedback mechanism that adapts the allocated bandwidth, or service rate,to maintain an average queue length which indirectly achieves the target‘short term’ loss requirement. It thereby only needs the long-termaverage arrival rate from the input traffic. However, in order to avoidbandwidth trashing and to keep a stable feedback control mechanism, thesolution is limited to control timescales in the order of 1 second orlonger.

The paper “Controlling Short-Term Packet Loss Ratios Using an AdaptivePushout Scheme” (Nananukul et al.; Proceedings of IEEE conf 2000Heidelberg Germany, June, pp. 49-54) describes a theoretical model tocharacterize a packet loss process accurately. It operates under theassumption that QoS requirements can be classified into packet delayrequirements and packet loss requirements. It proposes to includeshort-term packet loss ratios and maximum packet loss ratio on top oflong-term packet loss ratio to define a deterministic loss model. Itthen proposes an adaptive pushout scheme to selectively drop packets ata single network node which allows this single network node to monitorand control the packet loss process at this network node so that theflow locally conforms to the loss model. Simulations were performed atvery low service rates (64 kbps) to validate the results.

AIMS OF THE INVENTION

The present invention aims to provide a method and device forcharacterising a data flow in such a way that it reflects whether or notthe data flow can give rise to problems of packet loss when applied on acertain network path of a data transfer network. The invention furtheraims to provide a module for classifying the data flow according to saidcharacterisation.

SUMMARY

In a first aspect the present invention relates to a method forcharacterising a data flow in such a way that when transferring the dataflow over an IP network, the behaviour of the data flow remainspredictable, so that the transfer does not give rise to loss of parts(packets) of the data flow. A stable network environment is thusobtained. In an advantageous embodiment the data flow is a media flow. Amedia flow is to be construed as a flow of media related data.

More specifically, the invention discloses a method for characterising adata flow to be transferred over a network path of a network, wherebythe network path comprises at least one network device susceptible ofnetwork congestion. The method comprises the step of determining afootprint measure of the data flow. Said footprint measure provides anindication of a possible difference between the total amount of incomingdata and the total amount of outgoing data in the at least one networkdevice over a time interval having a duration of one or more time units,whereby that time unit is so chosen that individual data units of thedata flow are distinguishable by the network device. Individual dataunits can be individual bytes or a chunk of some bytes, or constitutecomplete packets or even a group of a few packets.

A crucial element in the invention is the concept of footprint measure.This measure is indicative of the burstiness of the data flow. In acertain way it yields a ‘footprint’ of the data flow in question. In theproposed solution it is essential that a footprint measure be determinedat a sufficiently high time resolution. With ‘sufficiently high’ ismeant at a timescale with time units corresponding in order of magnitudeto the length (duration) of bytes of a data packet of the data flow.Only then sufficient information is obtained to characterise the dataflow with enough detail to be able to configure the network path so asto combat packet loss efficiently. A footprint measure may be as shortas a single parameter indicative of the burstiness of the data flow, butit may also be represented as a set of parameters relevant to theburstiness. In any case the footprint measure reflects the behaviour ofthe flow over time.

The network path comprises at least one network device where possibly aproblem of congestion can occur during the data flow transfer. Thenetwork device may be a network switch, but can also be a source or evena destination. The footprint gives an indication of a possibledifference between the total amount of incoming data and the totalamount of outgoing data in the network device over a time interval thatcorresponds to one or more time units at the high time resolution aspreviously explained, i.e. time units so chosen that individual dataunits of the data flow (data packets or even just one or a few bytes ofa data packet) are distinguishable at byte level. The footprint measureindicates a possible difference, in the sense that it sets a level thatshould not be exceeded. In a preferred embodiment, wherein the footprintmeasure is represented by a single parameter, the footprint measure isset at the maximum difference between the total amount of incoming andoutgoing data that can possibly occur over any considered time interval.In this way it is guaranteed that packet loss is avoided. Alternatively,the possible difference can be derived from a prediction of the sourcebehaviour.

It is important to realise that during the transfer of the data flowover a network path of the (media) IP network, the footprint measure ofthe flow may change. This depends on the actual configuration of thenetwork path. For example, the presence of certain network devices andtheir configuration in the network path may be of influence, as well asthe presence of other flows and their footprint.

The determination of a footprint measure of a data flow according to theinvention can be performed off-line. It may for example be determinedvia measurements or predictions of the burstiness of the flow.

In a preferred embodiment the method of the invention comprises thefurther step of classifying the data flow according to the footprintmeasure as determined. The data flow thereby gets a kind of label tolink it with a specific class of data traffic. The method advantageouslycomprises the further step of determining, based on the classificationof the media flow, a Quality-of-Service (QoS) level. Such QoS level mayfor example relate to a priority level for the data flow. In a specificembodiment the QoS level is selected from a set of predefined QoSsettings. From the classification and, optionally, from additionalcharacteristics of the data flow a traffic passport can be generated forthat flow.

Advantageously at least one further characteristic of the data flow isdetermined. Parameters that provide useful additional information on thedata flow include, but are not limited to, delay, jitter, timingsensitivity, priority level. The at least one additional parameter ispreferably also taken into account in the classification step.

In another embodiment the method comprises the step of comparing thefootprint measure with the capacity of buffering means for storing atleast a part of the data flow, whereby the buffering means are part ofthe network device. Performing this step yields as a result informationon the risk of excess data in the network device.

The method advantageously comprises the further step of takingcounteraction to avoid packet loss in accordance with the result of thecomparing step. Alternatively, the decision on taking counteraction canbe based on the classification of the data flow. If one or more furthercharacteristics of the data flow have been determined or if suchcharacteristics can be collected from a database, the additionalinformation is preferably also taken into account when deciding on whichcounteraction is to be taken.

One counteraction that can be taken may be a scaling of the bufferingmeans of network device. The size of the buffering means is then adaptedto the footprint(s) of the relevant flow(s). Also traffic restrictionscan be imposed on the traffic over the network path. Another preferredcounteraction is shaping the traffic over the network path at a quantumtimescale. The shaping accuracy is typically in the order ofsubstantially a single data packet. In an embodiment this trafficshaping operation comprises in adapting the footprint measure bymodifying a parameter setting in a network device in the network path,so that at the output of the network device in question the data flowhas a different footprint measure than at the input, so that thetransfer of the data flow over the remainder of the network path cantake place without packet loss.

The invention also relates to a program, executable on a programmabledevice containing instructions which, when executed, perform the methodas previously described.

In another aspect the invention relates to a device for carrying out themethod as described, i.e. a device for characterising a data flow to betransferred over a network path of a network, whereby the network pathcomprises at least one network device susceptible of network congestion.The device comprises processing means for determining a footprintmeasure of the data flow to be transferred, said footprint measure beingindicative of a possible difference between the total amount of incomingdata and the total amount of outgoing data in the network device over atime interval having a duration of one or more time units. The time unitis thereby so chosen that individual data units of the at least one dataflow are at the level of bytes detectable or distinguishable by thenetwork device. The individual data units may contain a few bytes, acomplete data packet or even a few packets.

In an advantageous embodiment the device comprises means for classifyingthe data flow to be transferred over the network, said means beingarranged for receiving at least a part of the footprint measure. Thedevice further comprises a classification engine for classifying thedata flow based on the footprint measure.

In an embodiment the device comprises means for determining at least onecharacteristic of the data flow. Said means may be comprised in themeans for classifying.

In an advantageous embodiment the device is arranged for being connectedto a database wherein one or more characteristics of the data flow arestored.

In a further embodiment the device comprises comparing means forcomparing the footprint measure with the capacity of buffering means forstoring at least a part of the data flow, whereby the buffering meansare comprised in the at least one network device.

In a further aspect the invention relates to a module for classifying adata flow to be transmitted over a network path of a network for datatransfer. The module is arranged for receiving at least a part of afootprint measure of the data flow, said footprint measure beingindicative of a possible difference between the total amount of incomingdata and the total amount of outgoing data in a network device of thenetwork path over a time interval having a duration of one or more timeunits, whereby said time unit is so chosen that individual data units ofthe data flow are distinguishable at byte level by the network device,as previously explained. The module further comprises a classificationengine for classifying the data flow based on the footprint measure ofthe data flow.

The module preferably comprises means for determining at least onefurther characteristic of the data flow. The classification engine isthen preferably arranged for also taking into account the additionalcharacteristic(s) when classifying the data flow.

The classification engine is advantageously also arranged for beingconnected with a database comprising at least one further characteristicof the data flow to collect additional information from.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the sequential workflow model as known in the mediaindustry.

FIG. 2 illustrates an example of a digital media factory.

FIG. 3 illustrates the behaviour of large media file transfers over anIP network.

FIG. 4 illustrates the classical view on an IP network.

FIG. 5 illustrates the view on an IP network at ‘quantum’ timescale.

FIG. 6 illustrates the concept of footprint measure.

FIG. 7 illustrates the footprint measure of an incoming and outgoingflow of a network device.

FIG. 8 illustrates an example with a 10:1 oversubscription in thenetwork path.

FIG. 9 illustrates an example with two incoming media flows and a 2:1oversubscription.

FIG. 10 illustrates an example of a traffic type classification.

FIG. 11 illustrates more detail of the traffic classification.

FIG. 12 represents an example of a traffic passport.

FIG. 13 represents a scheme of the various layers of a multi-layer modelfor media data transfer.

DETAILED DESCRIPTION OF THE INVENTION

The invention capitalizes on an in-depth analysis of the differences inbehaviour of large media data transfers over IP networks as compared toIT traffic such as SAP traffic, MS Office documents or e-mails. ITtraffic typically consists of short messages or small files. The IPnetwork is typically used for only relatively small periods of time.Transfer speed is not critical. Packet loss and the resultingretransmission are acceptable. Media traffic, however, deals with verylarge files, generally a few gigabytes in size, transmitted at speedsfaster than real time, i.e. in relation to the video compression formatused. Hence, media traffic typically uses the link for a large timeperiod and almost constantly tries to use 100% of the availablebandwidth of the network infrastructure. The longer this period, themore bursty the traffic becomes. If different transfers share the samelink, bandwidth competition between individual concurrent transfersoccurs. This generates packet loss. The resulting retransmissionsdrastically decrease the overall efficiency of the transfers. Ifsustained, this can lead to complete transfer interruption.

First a detailed analysis of the difference between the network handlingof IT traffic and media traffic is given. The distinction between bothcan be made clearer by using the following analogy (see FIG. 3).Consider two IT clients, e.g. running Word and Excel, sending IT trafficat a speed of 400 Mb/s to a common file server. Suppose the trafficconsists of a small file or even simple commands in response to somekeystrokes of the user, resulting in 800 Mb/s being received by theserver. This type of traffic can be related to the way cars drive on atwo lane highway, see left hand side of FIG. 4. After passing the crosspoint, i.e. the switch, the two lanes have to merge into one lane. Mostof the time this happens quite efficiently without too much trafficdelay, since streams of cars nicely ‘zip’ together. In the ITenvironment the server indeed receives traffic at 800 Mb/s, without muchdelay. Bandwidth or throughput nicely adds up in a linear way in mostcases.

However, circumstances are different when dealing with transfers oflarge amounts of media data (see right hand side of FIG. 3). Now, thetraffic consists of sustained very large bursts of packets arriving backto back. Two clients sending simultaneously large files to the sameserver at 400 Mb/s no longer manage to get all the traffic through tothe server without interference. One could, using a similar analogy,describe the traffic as trains running on two tracks, where the switchacts like a junction. If both trains approach undisturbed the junctionat the same time, they crash into each other, leading to a catastrophe,and traffic is stopped. Consequently, the receiving media server doesnot attain an aggregated throughput of 800 Mb/s, but much less.Throughput can no longer be added linearly. Ideally, each train shouldhave its own track or otherwise traffic lights should be installed tomanage a possible congestion. Translated to the IP network world,ideally the architecture of the media IP network should provide forseparate links for each traffic flow. This is however only technicallyand practically feasible for very small setups.

Clearly, an IP network shows a different behaviour when loaded withtransfer of large amounts of media data. The IP network doesn't behave‘as expected’. Throughput decreases and becomes unpredictable. Transfersget lost. Above all, these effects are not limited to very largearchitectures, such as the digital media factory of FIG. 2. They alsoappear in very small installations with only a few clients and servers.The effects are not evidently visible when applying the classicalnetwork monitoring tools. IP networks, and more specifically IP overEthernet networks, are already being deployed by the IT industry formore or less three decades. It has become ‘the’ standard in local areanetworking in the enterprise world, the LAN. Together with theubiquitous adoption of this technology came along a large number ofnetwork monitoring practices and subsequent monitoring tools. Thesetools are however geared towards monitoring and managing IT traffic onIP networks and are certainly not optimized or adapted for tracking thespecific media traffic described above. They typically deal withmeasuring throughput by averaging over relatively long time intervals.When in the last couple of years this IT technology was introduced inthe media world of the broadcasters, the media engineers have embracedthe same monitoring tools to manage their media IP networks. They havelearned to apply the same monitoring practices to detect and resolvenetwork problems as the IT industry has been doing for decades. This iswhat further in this description is referred to as the ‘classical viewon an IP network’.

In order to deal with the ‘unexpected’ behaviour on the IP network inthe media environment, the way the network has to be monitored and thetools that have to be used are fundamentally different. With theapplication of IP technology in the media world, strange effects startedto appear that couldn't be explained by the ‘classical view’ held by theIT industry. These effects can only be explained if one starts to lookat the network on a completely different time scale, several orders ofmagnitude smaller than what classical network monitoring tools arecapable of. At that timescale concepts like ‘average network throughput’become meaningless, since the network starts to behave in a discreteway. A network link is loaded with a packet or it is idle. There is nosuch thing as a ‘bandwidth percentage’ anymore. One has to look at thenetwork in a quantised way. This way of looking at an IP network isreferred to as the ‘quantum view on an IP network’.

A typical environment where the ‘classical view’ starts to break down isa media web farm, i.e. a news web site enriched with a lot of videoitems (see FIG. 4). The architectural setup depicted on the left side ofFIG. 4 consists of three parts, namely an internal LAN with a text-basedback-end and the media file servers, a demilitarized zone (DMZ) networkwith the actual web servers and media front-end and the Internet,whereby all parts are separated by firewalls. The text-based web pagesare loaded from the ‘text-based’ back-end through the DMZ firewall tothe web front-end. The video items are loaded from the media fileservers via the same firewall to the media front-end. Hence, bothIT-type traffic, the web pages, and media traffic, the video clips, passvia the same link of the DMZ firewall. During high load of the web farm,suddenly and very unpredictably problems start to occur. The web site‘hangs’. The first network load report generated by the network providershows a flat continuous throughput of 10% of the full link capacity (seetop graph on FIG. 4). Traffic was sampled every 15 minutes. A moredetailed graph (2nd graph on FIG. 4), sampled every min, shows a similarbehaviour. The most detailed traffic view that could be provided showssome small peaks at 30% of the max throughput (see 3rd graph on FIG. 4,sampling period every 10 sec). This is the kind of information that istypically provided by the IT network monitoring tools. Clearly, thenetwork link of the DMZ is not the problem. However, deeper analysiswith a more specialised tool generated the bottom graph of FIG. 4, witha sampling period of 1 sec. The same small ‘30%’ peaks appear now tocompletely fill the link for a duration of 3 to 4 sec. During thesepeaks, the web server frontend can't reach its back-end. Thisconnectivity interruption can potentially be long enough to stall theweb farm application. This is an example where interference betweenmedia traffic and IT traffic on the same link has disrupted the properoperation of an ‘IT-type’ web application. Clearly, the classical ITnetwork monitoring tools and practises proved to be inadequate touncover the underlying problem and make a correct assessment of thesituation.

What has been described above, balances on the edge where the ‘classicalview’ is challenged. In a full blown media environment the followingmedia case clearly describes the underlying phenomena for the‘unexpected’ behaviour when large media transfers are involved (see FIG.5). In FIG. 5 two media clients are sending simultaneously a large mediafile towards the same server destination. All devices are connected byGb/s links. Media traffic consists typically of large bursts due to theprolonged sustained traffic. Suppose both clients are only using 10% ofthe bandwidth of their respective network link. The traffic of the leftclient uses bursts of 20 packets, while the right client uses 21 packetsper burst. Both transfers pass the switch and share the link towards thedestination server. The ‘classical view’ predicts that the total serverthroughput should be equal to the linear sum of the client throughputs,matching 200 Mb/s. This is apparently confirmed if throughput would bemeasured with a sampling interval of 100 msec. Note that this requiresan already more than 10 times more refined time resolution than thatavailable in the IT monitoring systems. At a sampling interval of stilla 1000 times more refined time resolution (100 μsec) the packet burstsor ‘trains’ should become visible (see second graph of FIG. 5). The timescale is still 10 times larger than the individual packets. One candistinguish the bursts of two flows overtaking each other. This resultsfrom the slight mismatch in packet burst length between the two flows.The individual bursts still appear to rise and fall in a continuous way.The two lower graphs zoom in on a timescale in the order of magnitude ofthe length of a single packet. Then the behaviour or characteristics atbyte level becomes apparent. The overlapping bursts are displayed. Now,the discrete quantised behaviour of the network becomes visible. This isa suitable timescale for a true ‘quantum view’ of the network. In somecases the quantum timescale can have time units at the order of thelength of one or more individual bytes. If a packet is transmitted, thelink is used for 100%. If no packet is transmitted, e.g. in between twobursts, the network link is idle. On this timescale there is no suchthing as 50% usage. During the burst overlap the following happens inthe switch. Two packets arrive at the same time into the switch. In thesame timeframe only one packet can leave the switch towards the server.One packet has to be buffered by the switch, until the outgoing linkbecomes idle. The vertical shaded bands indicate the buffer capacity ofthe switch. On the left of the lower graph, the buffer capacity islarger than the overlap of the two incoming bursts. The switch hasenough buffer capacity to store the excess of incoming packets, untilthe incoming bursts have passed. The switch then transmits the storedexcess of packets towards the server. The overall length of theresulting burst towards the server equals the sum of the length of thetwo incoming bursts. On the right of the graph, the situation isdepicted where the two incoming bursts precisely overlap in time. Here,the buffer capacity is too small to store all excess packets during thetotal overlap. Once the buffer exceeds its limits, the remaining excesspackets are being dropped by the switch. This example clearly indicatesthat in a classical IP network in a media environment, even at afraction of the maximum macroscopic bandwidth usage, packet loss can andwill occur.

The result of this effect depends on the network protocol being used. Inthe typical case of TCP, packet loss results in retransmissions and thesource throttles back its throughput. The total transfer time increasesdrastically and becomes unpredictable, which leads to a considerableloss in efficiency. Even worse, if the load increases and the packetloss is sustained, transfers possibly will fail, daemons can stopfunctioning and eventually the application can crash. The UDP protocolhas no mechanism to recover from packet loss. Hence, it is up to theapplication to deal with that problem. The classical network tools aredefinitely not able to monitor at this ‘quantum’ timescale. Thisrequires very specific capturing equipment. Due to the large amount ofdata that have to be captured, those devices can typically sustain suchprecise monitoring for only a few seconds. Hence, it is very difficultto detect precisely when this effect has happened in the field.

The described effect has to be extrapolated towards a productionenvironment as previously described where during peak load 500 or moresimultaneous file transfers are occurring, randomly distributed betweenany two servers. Typically some 100 transfers are being lost each day.

The fundamental characteristic of the IP traffic that is different inmedia compared to IT is the fact that media traffic typically consistsof large sustained packet bursts. If on top of that, different flowsshare a common link, they start to interfere with each other on a verysmall timescale, where the ‘quantum view’ rules. The interfering burstsgenerate a local oversubscription of the switch buffers on the ‘quantumtimescale’ which introduces packet loss. This occurs even if there issufficient bandwidth in the network on macroscopic timescale. Clearly,the classical view on an IP network is no longer valid in a file-basedmedia environment. In order to understand what happens, one has to lookat the network on a different level, on different timescale, withdifferent tools and new monitoring practices. The way IP traffic ischaracterised and defined in the IT world has to change in order to fitthe digital media challenge. Macroscopic quantities, such as averagebandwidth, oversubscription, available or used capacity are no longerthe only relevant parameters and have to be interpreted in a differentway. Additional specifications and definitions on the ‘quantum level’are required. Since continuous monitoring and measuring on this‘quantum’ timescale becomes problematic, a deeper understanding of thedetailed traffic characteristics and network switch and buffermechanisms have to be modelled. Out of these models new relevantmacroscopic and measurable quantities have to be identified.

The classical IT switches lack the proper buffers or Quality of Service(QoS) capabilities to tackle this issue. Or, in case high end switchesare being used, the QoS is not tuned nor implemented in a‘media-proficient’ way. It is critical to understand that IP switchesfor media are not a commodity like in IT networking. Moreover, thearchitecture of a typical IT network is not adapted to avoid or limitthis transfer interference. Oversubscription, even on a macroscopicscale, is more rule than exception in an IT environment. In a typicalfile-based media environment, the paradigm has changed from sequentialwork flows to concurrent work flows. Traffic flows are dynamicallychanging every moment. The architecture has become client-server andserver-to-server based. This results in a any-to-any traffic pattern.There is typically no central traffic management system in place thatcontrols and actively manages all different transfers. Moreover, part ofthe environment is client driven. Therefore, client interactionsgenerate a substantial part of the traffic. Even designed properly, theIP network is not capable of handling that continuously changing load inan adequate way. Media work flows translate into complex data flows. Onehas to take into account the characteristics of file-based mediaservices to perform this translation. If the media infrastructure is notproperly designed and integrated to guarantee an efficient use of itsresources, additional traffic load is generated. This only adds to theoverall problem.

A classical IT network displays the above described ‘unexpected’behaviour when faced with media traffic, with undesirable andunacceptable side effects for file-based media environments. Therefore,the prime objective for a media IP network architecture is to avoid thisunexpected behaviour. This translates into the following requirements:

-   -   a stable network environment where no media transfers or flows        are lost    -   a predictable behaviour. This requires a fundamental        understanding of the model under which the network operates and        functions, on macroscopic, microscopic and quantum level. This        particularly includes the precise interaction between media        traffic on the one hand, and the network topology and switch        functionality on the other.    -   a highly efficient usage of the available bandwidth. This        implies a maximal occupancy of the link bandwidth. The network        should not introduce by itself, i.e. independent of the source        flow characteristics, additional macroscopic fluctuations of the        end-to-end throughput of any media flow, unless operating in a        best-effort mode, or under a best-effort service-level-agreement        (SLA) per flow.    -   An optimal response to the particular SLA per traffic class, or        more specifically per media flow or transfer.    -   Ability to operate in an any-to-any traffic pattern, i.e. media        server-to-media server, opposed to, but not excluding, the more        prevalent client-server traffic pattern of a typical IT        environment.    -   Scalability up to and well over 1000 source/destination pairs.        In present file-based media environments most servers are        connected by Gb/s links. However, 10 Gb/s is slowly being        introduced as server connectivity link.    -   Full redundancy wherever source and destination media devices        allow it.

Some definitions are now stated that will be used throughout the rest ofthis description. The ingress side (point/port/switch) of a networkmeans is the network location/port/switch where traffic from a source isintroduced into the IP network and possibly mixed with other traffic.This is typically the network/switch port(s) directly connected to thesource NIC interface. However, if the source traffic follows anexclusive dedicated path further in the network before it is mixed withother traffic, any port along that path could qualify as the ingresspoint. The egress side (point/port/switch) of network means the networklocation/port/switch where traffic to a destination is collected andsplit from all traffic to other destinations. This is typically thenetwork/switch port(s) directly connected to the destination NICinterface. However, if the destination traffic follows an exclusivededicated path in the network after it is split from other traffic, anyport along that path could qualify as the egress point. The term ‘pointof congestion’ refers to the location in the network where differenttraffic flows come together and possibly interfere with each other. Itis to be noted that the term ‘point of congestion’ also refers to alocation in the network where due to a bandwidth mismatch between thelink of the incoming traffic and the link of the outgoing traffic abottle-neck can occur. It is further to be noted that a media server ora server in a media environment is meant to include high bandwidth‘client’ devices.

A definition of timescale is in general relative to the link bandwidth(e.g. 100 Mb/s, 1 Gb/s, 10 Gb/s) and to the size of the relevant switchbuffers. With ‘quantum timescale’ is meant a scale of time units in theorder of the duration of the individual data units of the data flow.Individual units can be as small as a single byte of a data packet or afew bytes. The timescale is thus at byte level. An individual data unitmay however also be larger, i.e. a data packet or a part thereof or afew data packets. As an example, assuming a full length packet of 1538bytes (7 bytes preamble, 1 byte start-of-frame (SOF), 1500 bytespayload, 14 bytes header, 4 bytes checksum and an inter-frame gap of 12bytes), a ‘quantum timescale’ has time units in the order of 1.23 μs incase of a 10 Gb/s link, of 12.3 μs for a 1 Gb/s link or 123 μs for a 100Mb/s link. In another example, assuming a single byte as a data unit, a‘quantum timescale’ has time units in the order of 0.001 μs in case of a10 Gb/s link, of 0.01 μs for a 1 Gb/s link or 0.1 μs for a 100 Mb/slink.

The timescale used to define the classical average bandwidth is referredto as ‘macroscopic timescale’. A macroscopic timescale has units in theorder of magnitude of seconds or minutes. In between macroscopic andquantum timescale one can define a microscopic timescale that may have atime unit in the order of a few packets or parts of packets. In thecontext of a switching device the microscopic timescale may be of thesame order or somewhat less than the length of the relevant switchbuffer (expressed in time instead of in buffer capacity, whereby thelink speed is taken into account).

In the invention a data flow is characterised by a footprint measure atquantum level. Providing this footprint measure at quantum level is thekey feature of this invention to solve the problems encountered in theprior art. However, it is to be noted that a footprint measure can alsobe considered at a macroscopic or a microscopic or quantum timescale. Afootprint measure represents a measure for the burstiness of the dataflow (e.g. a media flow) on the relevant timescale, related to a burstsize that creates an excess of data on top of the bandwidth on thattimescale in a network device located in the path over which the dataflow is transferred. The footprint measure gives an indication of thedifference between the total amount of incoming and outgoing data in thenetwork device over a time interval of one or more time units on therelevant timescale. For example, for a footprint measure at quantumtimescale, the time unit must be chosen such that individual data unitsof the media flow are distinguishable (or detectable) by the networkdevice, i.e. at byte level. The footprint then gives an indication ofwhether at quantum level there is a risk of excess data. The footprintmeasure is advantageously set equal to the maximum difference betweenthe amount of incoming and outgoing data in the network device thatpossibly can occur. Taking into account a footprint measure atmacroscopic and/or microscopic timescale advantageously yieldsadditional information on top of the info from the quantum levelfootprint.

Some examples are now provided to illustrate the notion of footprintmeasure. For the sake of simplicity in these example packets of equallength are considered. However, the same principles apply when packetsof different lengths are involved in the flow. A first example describesat a more conceptual level the quantum footprint of a media flow inrelation to its macroscopic average throughput. It is to be noted thatthe concept of quantum footprint can be related to any possible virtualreference shaping applied to the media flow. In this example themacroscopic average throughput of the media flow is assumed to be 50% ofthe link bandwidth (FIG. 6 a). On a quantum timescale the media flowconsists of bursts of 10 packets interleaved with a gap of the sameduration as the bursts (FIG. 6 b). FIG. 6 c displays the throughput on aquantum timescale if the media flow was to be shaped at 50% at quantumtime scale by some network device into separate packets interleaved witha gap of one packet duration. The shaping shown in FIG. 6 c can beconsidered as one of the possible virtual reference shapings mentionedabove. FIG. 6 d compares the original quantum throughput of FIG. 6 bwith the shaped quantum throughput of the media flow as shown in FIG. 6c. The maximum difference or the excess of packets is a possible measureof the quantum footprint of the original media flow.

A next example describes the quantum footprint of a similar media flowwith an average throughput of 50% of the link bandwidth, but this timeconsisting of irregular packet bursts, as shown in FIG. 6 e. Compared tothe same quantum shaped flow of FIG. 6 c, this gives a slightly higherdifference or excess of packets (see FIG. 6 f), indicating the mediaflow has a higher quantum footprint than in FIG. 6 d.

The quantum shaping at 50% as conceptually shown above can be the resultof an operation of a network device arranged for changing the quantumshape of the incoming media flow (FIG. 7). The bursts already shown inFIG. 6 b are received at the input of the network device. The devicethen performs a traffic shaping at 50%, yielding the shaped flow alreadyshown in FIG. 6 c.

In the example illustrated in FIG. 8 the quantum footprint of a mediaflow is described as a result of the passing through a network device,with an incoming link bandwidth of 10 Gb/s and an outgoing linkbandwidth of 1 Gb/s. This is an example of a 10:1 oversubscription inthe media flow path. Here, a macroscopic average throughput of 10% isthe result of a reoccurring burst of two packets. The link of theoutgoing flow is completely saturated at 1 Gb/s resulting in acontinuous burst. The quantum footprint of the incoming media flow atthe network device in this case corresponds to exactly one packet.

FIG. 9 illustrates an example with a 2:1 oversubscription in the mediaflow path, whereby two incoming flows enter a network device and exitthe device via only one link of the same bandwidth. Both incoming flowsare assumed to have a macroscopic average throughput of 25% of the linkbandwidth. It is further assumed that both flows have an identicalburstiness, shifted in time compared to each other. The resultingmacroscopic average throughput of the output flow equals the sum of themacroscopic average throughputs of the incoming flows. On a quantum timescale the output flow consists of bursts with a length equal to the sumof the length of the bursts of the incoming flows. Both incoming flowshave an identical quantum footprint (see FIG. 9 a). The quantumfootprint of the resulting flow (shown in FIG. 9 b) is higher than thatof each incoming flow. The quantum footprint of the sum of the incomingflows in the network device related to the output flow is shown in FIG.9 c. This quantum footprint is a measure of the buffer filling withinthe network device.

Based on the footprint measure as described above, a media trafficclassification can be defined. Each media flow can be characterised andlinked to a specific class. Optionally, a ‘traffic flow passport’ can begenerated per flow. As already mentioned, the fundamental characteristicof the media IP traffic is the abundant presence of large sustainedpacket bursts. There are various flavours of media traffic that generatean unexpected IP network behaviour as previously described. Someexamples are large file transfers, real-time streaming traffic, storagetraffic, file system traffic etc. . . . Each has slightly differentspecifications. However, they all share burstiness as common primecharacteristic.

A classification of each relevant, though distinctive type of mediatraffic is a substantial step towards a total solution wherein packetloss is effectively combated. A set of characteristics andspecifications for each class has to be defined. The specific details ofeach class should be chosen to be distinctive so that they warrant adifferent processing of the traffic by the IP network, possibly even aspecific optimisation of the network architecture. This probably leadsto different QoS characteristics and settings of the switches in thenetwork per class. Traditional IT traffic is included as an additionalclass. The classification shown in FIG. 10 is given as an indicativeexample and will be further expanded both in type of classes, as well aswithin each class into specific subclasses.

In this example the flows between each different combination of mediasource-destination pair are so chosen that they belong to a differenttraffic class. E.g. the flow between Source1 (51) and destination n (Dn)belongs to traffic class X, between Source2 (S2) and destination 1 (D1)belongs to traffic class Y, etc. . . . Therefore, all network devices inthe path of traffic class X could have a QoS characteristic setting,characteristic to the requirements of traffic class X. In particular,these QoS characteristic settings can be applied to the relevant portsin the path, but can also imply a more general setting of the networkdevice. Similarly, the network devices in the paths of the other classescan have distinctive QoS settings corresponding to their requirements.

The particular traffic flows generated by each source should bequantified by its relevant characteristics and specifications. Inparticular, its footprints should be determined. A set of tests can bedevised to accomplish this, using specific lab equipment as mentionedbefore. Alternatively, footprints can be predicted based on availableperformance information. At least a quantum footprint is needed, but amacroscopic and/or a microscopic footprint may provide additionalrelevant information. Each traffic flow from a source or source instancecan then be linked to a specific traffic class and accompanied by a listof more detailed relevant flow specific specs. This leads to a kind of‘traffic flow passport’. While traffic classes are generic, eachspecific source flow qualifies under a certain class but requiresspecific parameters. As an example a provisional non-exhaustive trafficclassification is given in FIG. 11. An example of a traffic passport isgiven in FIG. 12, where the specific traffic class of large filetransfer is shown. Note that in this figure some additional fields arementioned that were hidden in FIG. 11. Large file transfer typicallyconsists of (enhanced) ftp transport of very large (+1 GByte) mediafiles between 1 Gb/s enabled servers (server-to-server) residing in thecloud of the media environment. An extension to 10 Gb/s enabled serversmay be possible in the future. Traffic typically consists of very largebursts of packets, since traffic content mainly comprises continuousvery large files and transfers flow uninterrupted between source anddestination. The network protocol is TCP which allows for network flowcontrol. Tuning of TCP stack parameters is possible as long as thesource and/or destination servers are not to be treated as a black box.If the application is ardftp, a possible source BW limitation and evenquantum footprint manipulation could be possible. QoS is directed tohigh efficiency and predictability. Subclass 1 has high prioritydemanding no additional induced BW reduction. Subclass 2 has lowpriority with possible destination oversubscription leading toadditional BW reduction. Subclass 2 has no delay or jitter sensitivity.Only small variation in microscopic/macroscopic bandwidth at the sourceis to be expected. Overall macroscopic bandwidth should be stable andpredictable (for subclass 1). Multiple large file transfers could bedirected to the same destination server interface creating a many-to-onedestination oversubscription (depending on whether the trafficmanagement system would allow this to happen, which distinguishessubclass 1 from subclass 2). A typical source interface could generatemultiple file transfers towards multiple destinations leading to amany-to-many traffic pattern. Large file transfer traffic is setup by aworkflow/traffic management system between two media servers (e.g. mediafile cluster server, ingest server, trans-coding server, . . . ),equipped with 1 Gb/s interfaces. In the future, a 10 Gb/s equippedserver could serve multiple 1 Gb/s servers creating a destinationoversubscription from bandwidth mismatch between source and destination.Bandwidth and priority can be enforced by a workflow/traffic managementsystem (see below for more details).

Every specific implementation of a media environment consists ofspecific traffic flows. These particular flows can be classified intomore generic traffic classes. Not all traffic classes have to be presentin every media environment. Together with the classification, thelocation of all source/destination combinations per traffic class shouldbe mapped on the total network architecture or topology. The combinationof the identified relevant traffic class and its particularsource/destination locations defines a traffic class pattern over thenetwork architecture. The mapping of all these traffic class patterns onthe network topology should result in a distribution map of the trafficclass patterns over time. This distribution map can be static, i.e. thedistribution of the classes over the network architecture remainsconstant. Alternatively, the distribution of the traffic class patternscan change over time, even on a relatively short macroscopic timescale.

The media IP network architecture should be designed such that itoptimally accommodates the distribution of those specific traffic classpatterns. This can possibly lead to a subdivision or portioning of theoverall network architecture into smaller network parts, each with aparticular architecture or topology, adapted to the specificrequirements of the traffic class(es) that belong to the identifiedsource/destination groups.

Distinction can be made between the physical network infrastructure onthe one hand and on the other hand the configuration of the switchesincluding the routing, which defines the logical network topology, andthe applied quality of service (QoS), which defines the handling of thetraffic on top of the logical network topology. The physical networkinfrastructure should be optimally designed to support all relevantpossible traffic class pattern distributions. A static configuration ofthe network architecture should accommodate this traffic class patterndistribution. In an advantageous embodiment the network provides thepossibility to dynamically (re)configure the logical topology, e.g. byadapting the routing, and/or the network components, i.e. adapting theQoS of the switches, to accommodate the dynamical changes in the trafficclass pattern. In another preferred embodiment the configuration couldbe statically or dynamically tuneable to optimise the networkarchitecture for the particular detailed specifications and SLA of theindividual traffic flows and the traffic flow combinations. The proposeddynamical reconfigurations can be performed by a traffic managementsystem (see below for more details).

The prime cause for the ‘unexpected’ behaviour of an IP network, whenfaced with media traffic, is packet loss. Hence, packet loss has to beavoided at all cost, if possible. The principle tools to tackle thisissue include network topology, Quality-of-Service (buffering, queuing,priority, bandwidth provisioning, . . . ), traffic management, flowcontrol on protocol level and flow control on link level (IEEE802.3x andevolutions) (lossless Ethernet).

Packet loss in a media environment is primarily linked to two differentoversubscription conditions. With oversubscription is meant that moretraffic is coming in than can be processed or forwarded by theport/device/resource. The first is the macroscopic oversubscription atpoints of congestion in the network, i.e. sustained oversubscriptionbased on a macroscopic timescale or on macroscopic bandwidth. The othercondition is oversubscription at points of congestion of the network atquantum timescale. The points of congestion are typically, but notexclusively, found at the egress side of the network. Note that as longas the backbone design can be considered as a non-blocking timemultiplexer, the backbone should be transparent to quantumoversubscription and not be considered as a point of interference. Thischanges however once 10 Gb/s links are used as source links, matchingthe bandwidth of an individual backbone link.

Macroscopic oversubscription can be prevented by using anon-oversubscribed network topology, whereby all points of interference(i.e. all points of congestion) are eliminated, e.g. by providing everypossibly interfering flow with its own link or path through the networkwherever necessary. Further proper traffic restrictions can be provided.The sum of the macroscopic bandwidth of all traffic directed towards thesame shared link should not exceed the physical link bandwidth. This canbe avoided by enforcing traffic restrictions statically or by a trafficmanagement system. Some control over the macroscopic bandwidth of eachinvolved source is required. This can be accomplished by bandwidthlimitation at the source itself or at the ingress point of the network,e.g. by traffic shaping. Sufficient buffering should be provided.Macroscopic oversubscription can be actively overcome by counting on theflow control capabilities of the network protocol, the link, theindividual network switch or the complete end-to-end networkinfrastructure:

-   -   TCP: Buffering at the interference point can kick in the flow        control before packets are dropped, if the buffers of the        source/destination TCP stacks can be properly tuned in relation        to the network buffers involved. This is not always possible        with proprietary media servers. Sufficient buffering at the        interference point should be provided.    -   UDP: Bandwidth limitation at the ingress point of the network,        e.g. by traffic shaping, together with the use of IEEE802.3x        link flow control can throttle back the bandwidth of the source.        Sufficient buffering at the ingress point should be provided. As        a last resort, packet drop could be used to limit the bandwidth.        Since UDP has no flow control, it is up to the application layer        to recover.    -   Lossless network components, such as Data Centre Ethernet        switches can be used to create a lossless end-to-end network        architecture.

The avoidance of macroscopic oversubscription, however, is notsufficient to eliminate the packet loss. In order to eliminate thesecond cause of packet loss, the quantum oversubscription at theinterference point shouldn't exceed the buffer capacity of thecongestion point. In other words, when looking at a timescale expressedin time units corresponding in duration to the order of magnitude ofindividual data units, the storage capacity of the network device wherethe interference point occurs, should be big enough to store the excessdata packets. If not, then packet loss occurs. To accomplish this, thequantum footprint of each of the interfering flows has to be controlled.This allows for a predictive modelling of the quantum oversubscriptionat the interference point. Subsequently the aggregated quantum footprintcan be matched not to exceed the available buffering. This can be doneby applying ‘quantum shaping’ (see further) at the ingress side of eachof the participating flows. However, if many packets are buffered at theinterference point, flow control could inadvertently kick in to reducethe source throughput, hereby creating an undesirable side effect sincemacroscopic throughput will be decreased and transfer efficiency willsuffer. This in turn automatically influences the output of the quantumshaping and reduces further the quantum footprint. Evidently, whichflows share the same link and possible interfere should be controlledstatically or by the traffic management system. The specifications ofthese selected flows define the degree of quantum shaping required foreach flow.

Proper application of priority queuing, e.g. at the egress side of thenetwork, could be used to differentiate between particular SLAs of thedifferent traffic classes, if desired. In case of TCP traffic, amechanism has to be provided to guarantee that ACK packets arrive withminimal delay back at the source. Otherwise, this would disturb the flowcontrol mechanism and decrease the overall efficient use of availablebandwidth.

Other QoS mechanisms than priority queuing can be used to optimallyaccommodate for the requested specifications or SLA of each individualflow or generic traffic class in general. E.g. bandwidth provisioningcan be used for providing lower priority traffic flows with a fair shareof the remaining bandwidth.

Latency and jitter are typically characteristic requirements includedinto the specifications of particular traffic classes, as well as timingsensitivity, priority level, . . . . The quantum footprint of theindividual flows and the quantum oversubscription of interfering flowsare two primary concepts that will influence latency and jitter. Hence,the mechanisms to avoid packet loss described above, especially thoseconcerning the quantum oversubscription, have to be taken intoconsideration when defining or estimating possible and acceptablelatency and jitter. Also the network topology, the number of hops andthe latency within each switch can add a determining contribution injitter and latency.

On the other hand, latency and jitter restrictions, enforced by the SLAof the relevant traffic classes or individual flows, influence theallowed range of applied quantum footprints and consequently quantumshaping on the respective sources and on the quantum oversubscription atpoints of interference.

All the above requirements have to be taken into account in determiningthe architecture of a media IP network. According to the requiredfunctionalities at each point or position in the network, i.e. atingress, backbone or egress point, an appropriate selection of theswitches with the proper characteristics and features is crucial.Depending on the choice of the available features, the technicalimplementation and their proper configuration, more or less‘media-awareness’ of the IP network can be provided. Additionalfunctionality and optimisation could be provided if dynamical(re-)configuration by a supervising traffic management system ispossible.

Traffic shaping retains excess packets above the committed rates in aqueue and then schedules the excess for later transmission overincrements of time. This smooths bursty traffic rates out. Mostly aleaky bucket scheduling mechanism is used for the later transmission ofany delayed packet. This introduces a kind of credit system. As long asthe leaky bucket is not completely filled, each arriving packet adds acredit to the leaky bucket and the packet is immediately forwarded. Thescheduler ‘leaks’ credits out of the bucket at a regular time interval.If the bucket is full, packets are retained in the buffer for latertransmission. Thus, at any time, the largest burst a source can sendinto the network is roughly proportional to the size of the bucket.

A side effect of this mechanism is that the shaping only kicks in afteran initial burst required to fill up the bucket is transmitted withoutdelay. This effect repeats itself as soon as incoming traffic is lowerthan the committed or emptying rate of the bucket. Hence, this shapingimplementation doesn't guarantee a precisely controlled quantumfootprint of the shaped flow.

In order to avoid packet loss, the aggregated quantum footprint ofinterfering flows has to be precisely managed not to exceed theavailable buffering (see above). This can be accomplished by controllingvery precisely the quantum footprint of each of the interfering flows atthe ingress point in the network. Shaping with substantially singlepacket accuracy is required. This is defined as ‘quantum shaping’hereafter. Hence, the above described classical implementation oftraffic shaping does not suffice. The main characteristics of shaping atquantum level are:

-   -   the shaping is performed on a quantum timescale with a quantum        timescale accuracy    -   shaping at the committed rate of 50% or less using a single        packet burst size should be possible    -   no packet burst should leak at the start of shaping. The shaping        has to start from the first packets onwards.    -   no packet credits should be accumulated    -   shaping should be possible at the ingress point of the network    -   possible shaping rate should be definable at any bandwidth and        not only at ½, ⅓, . . . , 1/n but preferably at any percentage    -   shaping above 50% may require a multi-packet burst length or a        smaller gap between consecutive frames    -   shaping with multiple packet burst size should be possible even        for shaping rates at or below 50%.    -   to limit latency and jitter for frame sensitive traffic (e.g.        Real Time streaming traffic) it should be convenient to be able        to shape ‘within an applied envelope’, e.g. so as to pass each        video frame within an integral burst.        The quantum shaping capability is a critical factor in the        design of a ‘media-aware’ IP network.

A classical IT network operates in a best-effort mode. Hence, there isno reason to implement traffic management systems in an IT environment.Surprisingly enough, also media environments lack any traffic managementfunctionality. Only the media asset management (MAM) system has somelimited notice of work flows. Most popular MAM systems available todayare integrated product suites. Apart from managing the essence and itsmetadata, they also have limited knowledge about some of the includedmedia services, such as ingest sources and trans-coding engines.

As explained earlier, file-based work flows mimic closely lineartape-based work flows. The resulting data flows are not optimised. Eventhe most advanced MAM system provides very limited effective loadbalancing functions, and no active traffic management at all, as it hasno idea of the underlying IP network topology. Data flows are hardcodedinto the MAM system product by the supplier. Hence, activereconfiguration of the underlying IP network is absolutely impossible.The MAM system has no idea about macroscopic oversubscription, let alonequantum oversubscription. Transfers are just launched as such, withoutany priority, QoS or enforced SLA. At best, failing transfers are loggedred and successful transfer status are flagged green. Other transfersbetween systems or media services that are not under the control of theMAM system, just coexist on the network. Hence, it is no surprise thattraffic interference exists. Due to the peculiar characteristics ofmedia flows, packet loss occurs. Transfers slow down and sometimes evenfail. There is definitely a need for a traffic management system that isaware of the network architecture and topology, the traffic flowcharacteristics and the possible oversubscription conflicts with mediatraffic.

In an aspect the invention relates to a management system forconfiguring a network path of a network for transferring a media flowthat comprises a traffic management module, that can determine at leastone possible path for transferring between possible locations of sourceand destination a media flow classified according to a quantum footprintas previously discussed. The management system is illustrated in FIG.13.

The traffic management module may advantageously be part of a severallayer management system. At its lowest level (layer 0) a media trafficclassification module as previously presented is found. Said module cancharacterise each media flow and link it to a specified class, wherebyoptionally a traffic flow passport is generated. At layer 1 of themanagement system the IP media network architecture (i.e. the physicallayer) is designed to optimally accommodate media flows and trafficclasses defined at layer 0. Network devices are selected that can beconfigured with the proper QoS characteristics to avoid packet loss. Thetraffic management module is situated at layer 2 (see FIG. 13). Themodule controls the actual media transfers. It is preferably capable ofdynamically reconfiguring the appropriate devices in the traffic path toreserve the necessary network resources and to implement the correct QoSsettings to ensure that packet loss is avoided. It launches the transferand starts monitoring the traffic counters from the network to track thestatus of the transfer. The progress of the ongoing transfer is reportedback to the data flow management module at layer 3 (see FIG. 13). Thedata flow management module determines the most optimal physicalsequence of media transfers, corresponding to the logical data flow thatis requested by the work flow management layer on top. It is alsoresponsible for the accompanying metadata information flow between therelevant systems. It commands the actual execution of the physical mediatransfers to the traffic management layer below and receives feedback onthe progress of the media transfers. The data management keeps track ofthe progress of the data flow and its components, and reports the statusof the data flow as a whole back to the supervising work flow managementmodule. At the top layer, business processes are translated in terms ofwork flows. These work flows in turn result in a logical data flows. Thework flow management module passes the execution request for the logicaldata flow down to the data flow management system below. It gets statusfeedback from the data flow management module and keeps track of thestatus of the requested work flows.

Further details on the traffic management module are now provided. Inthe invention the specifications of all media transfers are identifiedand flows are classified into generic traffic classes (see layer 0). Themedia IP network architecture and topology is optimised for passingmedia traffic without packet loss. The network is statically configuredto accommodate the relevant traffic class patterns (see layer 1). Thenetwork should have the technological capability to accept thepredefined QoS settings to avoid both macroscopic and quantumoversubscription on the points of interference. It is up to the trafficmanagement to enforce these settings, if possible dynamically, given thedefined traffic patterns and flows, and to guarantee that macroscopicoversubscription is avoided and to control quantum oversubscription sothat no ‘unexpected’ behaviour occurs. The traffic management systemshould also actively monitor the correct network components in order totrack the status of the ongoing transfers.

There are at least two main sources that can trigger media traffic flowsover the network and that require action of the traffic managementsystem, namely the work flow driven media traffic flows and the useraction generated media traffic.

In the work flow driven case, the work flow management system (see layer4 in FIG. 13) launches a certain work flow. This process could e.g. betriggered by a user action or an automated process. The work flowmanagement system translates the work flow into an optimal logical dataflow using knowledge of the available media services. It passes therequest down to the data flow management system (see layer 3). At thenext lower layer, the data flow management system has an even moredetailed knowledge about the media service architecture and theunderlying infrastructure. It should keep track of the available mediaservice resources and be kept aware of the present load on the networkinfrastructure by the traffic management system. This should allow thedata flow management system to take into account the macroscopicbandwidth requirements and existing macroscopic oversubscriptionconflicts. It uses this knowledge to load balance the data flow betweenthe relevant media services and selects the optimal source/destinationpairs. It then commands the traffic management system to execute thedefined traffic flows with the correct SLA, QoS, traffic class and otherspecifications defined at layer 0. If necessary, the traffic managementsystem dynamically reconfigures the appropriate devices in the trafficpath to reserve the necessary network resources and to implement thecorrect QoS settings. It thereby enforces that macroscopicoversubscription is avoided and effectively controls quantumoversubscription to avoid packet loss by all the means and mechanismsdescribed earlier (see layer 1).

It starts monitoring the traffic counters from the relevant networkdevices in order to track the status of the forthcoming transfer. If thetransfer type allows it, the traffic management system then sets up thenecessary connection between source and destination and launches thetransfer. Otherwise it should signal the system responsible for thestart of the transfer, possibly the source itself, that the network isproperly configured and that the transfer can proceed. The setup andlaunching of the transfer could make use of a kind of service or messagebus, possibly but not necessarily based on a service orientedarchitecture, or point-to-point integration architecture. The progressof the ongoing transfer is reported back to the data flow managementsystem.

If the media traffic is generated by user actions, e.g. in the case of ahigh resolution editing process, the traffic management can only reserveand reconfigure the proper network resources belonging to that specificmedia flow or traffic type class between the selected source/destinationpairs. The request could possibly be triggered by a planning schedule, auser logon on a certain system, or even by a static reservation of somekind. However, the media traffic flows themselves cannot be launched orcontrolled by the traffic management system. Monitoring is evidentlypossible and even necessary to track the availability of all resources.

In case of a new request for an urgent media transfer with highpriority, the traffic management system could intervene pre-emptively,and reconfigure the network to e.g. stop, delay or slow down existingmedia flows, in favour of the transfer with higher priority.

If no work flow or data flow management system exists, the trafficmanagement system should be able to perform its elementary functionsindependently, e.g. by means of a cockpit application to manuallyreconfigure the necessary resources, and provide the monitoring functionof the status of the running transfers.

Data Flow Management Module—Media Services

At this layer resides the detailed overview of the media productionarchitecture, the media services and how they are integrated andconnected to each other.

The data flow management module should have a detailed model of theavailable media resources, their functionality and services, capacityand the bandwidth in between them. It also must keep track of the dataflows that are actually running over the infrastructure at all times, inorder to determine the remaining free resources. It has a macroscopicview on available and used bandwidth. It therefore should able to takemacroscopic oversubscription at interference points into account.However, it has no knowledge of the processes playing at the quantumtime-scale. Hence, it is completely oblivious about quantumoversubscription.

The data flow management module main task is to determine the mostoptimal physical sequence of media transfers, corresponding to thelogical data flow that is requested by the work flow management layer ontop. It has to take into account the actual load on the architecture andthe specifications of the traffic flows it wants to execute. It getspart of that information from the generic traffic class of theindividual flows. Another part comes from the particular specificationsdefined for each flow. And finally, the requirements linked to the workflow at hand define the scope and overall SLA in which the data flow andeach individual media transfer is positioned. Its macroscopic viewshould provide deep enough architectural knowledge to be able tooptimally load balance the physical flows over the available mediaservice resources. The data flow management module is also responsiblefor the accompanying metadata information flow between the relevantsystems. To fulfill that additional task, it could make use of a kind ofservice or message bus, possibly but not necessarily based on a serviceoriented architecture or point-to-point integration architecture. Itcommands the actual execution of the physical media transfers to thetraffic management layer. However, it is the task of the trafficmanagement module to actually setup, tune and reconfigure the networkresources and physically launch or trigger the launch of the transfers.

The data flow management is in continuous communication with the systemsin the layer below and above. The traffic management module reports backregularly on the progress of the media transfers. The data managementkeeps track of the progress of the data flow and its components andreports the status of the data flow as a whole back to the supervisingwork flow management module.

As described in the context of the traffic management module, thefunction of the data flow management system, if at all presentlyavailable in the existing media environments, resides mostly tightlyintegrated in the MAM systems. However, it doesn't belong to theessential functionalities of a MAM system. For the same reasons aslisted for the traffic management module it should be executed by anindependent system that has a complete picture of the media environment.

Work Flow Management Module

At the work flow management module layer, business processes aretranslated in terms of work flows. These work flows in turn result in alogical data flows. A kind of business process routing is defined. Thework flow management module is not concerned with the actual physicalconcatenation and implementation of the data flow, nor the resultingunderlying media transfers. Therefore, the work flow management moduleonly has to be aware of the logical concept of essential available mediaservices. It passes the execution request for the logical data flow downto the data flow management module (see layer 3).

As explained earlier, in most media environment today, file-based dataflows mimic closely linear tape-based data flows. This is not theresponsibility or fault of the work flow system, since it only dealswith the logical data flow. It typically concatenates functions offeredby media services together in order to define the task at hand. It is upto the underlying data flow management module to interpret the logicalconcatenation and, with its knowledge of the physical implementation andunderlying architecture, to optimise the resulting physical data flowand media transfers.

The work flow module is arranged for providing the followingfunctionalities:

-   -   a user interface to link media services together to define the        logical order of the different steps required by the business        process or work flow.    -   It requires a kind of database of available media services to        pick and choose the relevant services from and a mechanism to        link them.    -   Means to define some requirements in terms of a service level        agreement    -   Ability to store the resulting work flows and pass the execution        request down to the data flow management module.    -   It can get status feedback from the data flow management module    -   It is capable to keep track of the status of the requested work        flows.        The user interface and control over some of its functionalities        can be integrated in the client of the available MAM system.

Although the invention has been described above in the context of mediaflows, it will be clear to the person of skill that the same principlescan be applied to data flows with similar characteristics containingdata from another application field.

Although the present invention has been illustrated by reference tospecific embodiments, it will be apparent to those skilled in the artthat the invention is not limited to the details of the foregoingillustrative embodiments, and that the present invention may be embodiedwith various changes and modifications without departing from the scopethereof. The present embodiments are therefore to be considered in allrespects as illustrative and not restrictive, the scope of the inventionbeing indicated by the appended claims rather than by the foregoingdescription, and all changes which come within the meaning and range ofequivalency of the claims are therefore intended to be embraced therein.In other words, it is contemplated to cover any and all modifications,variations or equivalents that fall within the scope of the basicunderlying principles and whose essential attributes are claimed in thispatent application. It will furthermore be understood by the reader ofthis patent application that the words “comprising” or “comprise” do notexclude other elements or steps, that the words “a” or “an” do notexclude a plurality, and that a single element, such as a computersystem, a processor, or another integrated unit may fulfil the functionsof several means recited in the claims. Any reference signs in theclaims shall not be construed as limiting the respective claimsconcerned. The terms “first”, “second”, third”, “a”, “b”, “c”, and thelike, when used in the description or in the claims are introduced todistinguish between similar elements or steps and are not necessarilydescribing a sequential or chronological order. Similarly, the terms“top”, “bottom”, “over”, “under”, and the like are introduced fordescriptive purposes and not necessarily to denote relative positions.It is to be understood that the terms so used are interchangeable underappropriate circumstances and embodiments of the invention are capableof operating according to the present invention in other sequences, orin orientations different from the one(s) described or illustratedabove.

1. A method for characterising a data flow to be transferred over anetwork path of a network, said network path comprising at least onenetwork device susceptible of network congestion, said method comprisingthe step of determining a footprint measure of said data flow, saidfootprint measure being indicative of a possible difference between thetotal amount of incoming data and the total amount of outgoing data insaid at least one network device over a time interval having a durationof one or more time units, whereby said time unit is so chosen thatindividual data units of the data flow are distinguishable at byte levelby said at least one network device.
 2. The method for characterising asin claim 1, wherein a step is performed of classifying said data flowaccording to said footprint measure.
 3. The method for characterising asin claim 1, comprising the step of determining at least one furthercharacteristic of said data flow.
 4. The method for characterising as inclaim 3, whereby said at least one further characteristic is a parameterof the group of parameters comprising {delay, jitter, timingsensitivity, priority level}.
 5. The method for characterising as inclaim 1, comprising the further step of comparing the footprint measurewith the capacity of buffering means for storing at least a part of saiddata flow, said buffering means being comprised in said at least onenetwork device.
 6. The method for characterising as in claim 2, furthercomprising the step of taking counteraction to avoid packet loss inaccordance with the classified data flow.
 7. The method forcharacterising as in claim 6, whereby taking counteraction comprisesscaling said buffering means of said at least one network device.
 8. Themethod for characterising as in claim 6, whereby taking counteractioncomprises shaping the traffic over said network path at the level ofindividual data units.
 9. The method for characterising as in claim 8,whereby said traffic shaping comprises adapting said footprint measurein said at least one network device.
 10. The method for characterisingas in claim 2, comprising the step of determining a quality-of-servicelevel based on the classification of said at least one data flow. 11.The method for characterising as in claim 10, wherein thequality-of-service level is selected from a set of predefinedquality-of-service settings.
 12. A device for characterising a data flowto be transferred over a network path of a network, said network pathcomprising at least one network device susceptible of networkcongestion, whereby said device comprises processing means fordetermining a footprint measure of said data flow to be transferred,said footprint measure being indicative of a possible difference betweenthe total amount of incoming data and the total amount of outgoing datain said at least one network device over a time interval having aduration of one or more time units, whereby said time unit is so chosenthat individual data units of the data flow are distinguishable at bytelevel by said at least one network device.
 13. A device forcharacterising a media flow as in claim 12, further comprising a meansfor classifying said data flow to be transferred over said network, saidmeans for classifying being arranged for receiving at least a part ofsaid footprint measure and comprising a classification engine forclassifying said data flow based on said footprint measure.
 14. Thedevice as in claim 12, further comprising means for determining at leastone further characteristic of said data flow.
 15. The device as in claim12, arranged for being connected to a database wherein at least onefurther characteristic of said data flow is stored.
 16. A module forclassifying a data flow to be transmitted over a network path of anetwork for data transfer, said module being arranged for receiving atleast a part of a footprint measure of said data flow, said footprintmeasure being indicative of a possible difference between the totalamount of incoming data and the total amount of outgoing data in anetwork device of said network path over a time interval having aduration of one or more time units, said network device beingsusceptible of network congestion, whereby said time unit is so chosenthat individual data units of the data flow are distinguishable at bytelevel by said network device, said module further comprising aclassification engine for classifying said data flow based on saidfootprint measure of said data flow.